Need more time to look into the tests.

Test failures might be unrelated: #724.

But likely could use a test itself.

Build failed in a rebased branch.
https://travis-ci.org/junegunn/vim-plug/builds/604736561

I'll preface this by saying this is a bit of an odd case, and if vim-plug doesn't want to support this case, that's understandable to me (but it would be good to get a statement from maintainers one way or the other).

Black (a python code formatter) does a somewhat interesting thing with tags where, in addition to having version tags, there's a stable tag which gets moved around to whatever the latest release is. Their editor installation docs instruct to use this with vim-plug (yes, I know, they say branch and should probably say tag, but that's the second issue here). By default, git fetch --tags and git pull --tags won't clobber existing tags if they've changed, but in this case that's exactly what needs to happen. (Related upstream issue: psf/black#2503) This can be fixed by using the force flag. So, for example git fetch/pull -q --tags --force.

So, if when fetching the tags (like in this PR) --force was also used, it would satisfy projects which have a stable or latest tag that moves around with new releases. Then Black's docs could be changed to something like Plug 'psf/black, { 'tag': 'stable' } and vim-plug would work for getting the latest stable version of the plugin.

Is this something maintainers would be ok with? I mention here because tag-fetching seems mostly done already here (failing tests notwithstanding)

@matthewarmand

there's a stable tag which gets moved around

That's a strange practice. Not sure if we should enforce --force for an exceptional case.

But since they also publish version tags, you can do something like this:

" *.* to match version numbers
Plug 'psf/black', { 'tag': '*.*' }

Updated. Elapsed time: 2.342714 sec.
[=]

- Finishing ... Done!
- Latest tag for *.* -> 22.3.0 (black)
- black: Resolving deltas: 100% (5459/5459), done.

Thanks @junegunn, I agree that's a much better solution. I'll open a PR soon over there suggesting that change in their docs (I had another addition I wanted to make anyway).